NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/9

Internet Message Format | 1996-08-06 | 4KB

Path: cygnus.com!not-for-mail
From: [e-mail] (Ronald F. Guilmette)
Newsgroups: comp.std.unix,comp.std.c
Subject: A question about FILEs (with relevance to POSIX threads).
Followup-To: comp.std.unix
Date: 1 Jan 1996 16:34:02 -0800
Organization: Infinite Monkeys & Co.
Sender: [e-mail]
Approved: [e-mail] (Moderator, Sean Eric Fagan)
Message-ID: <4c9uhq$[e-mail]>
NNTP-Posting-Host: cygnus.com
X-Submissions: [e-mail]

Submitted-by: [e-mail] (Ronald F. Guilmette)

Greetings all.

I'd like to start out the new year with a simple (but perhaps obscure)
question about FILE structures.

This is not so much a question of what the standard says as it is a
question of why traditional implementations are the way they are.
(Lest Norman or anyone else remind me, I _am_ aware that such ques-
tions are normally considered somewhat off-topic for comp.std.c, but
please bear with me.  I need to put this question to _implementors_,
and this is the best forum to obtain the ear of such people.)

Quite simply, I'd like to know why traditional implementations of the
C language (in both its ANSI/ISO and pre-ANSI/ISO flavors) are in the
habit of statically allocating a fixed length array of FILE structures
(for the program to use) rather than (say) using malloc to allocate a
new FILE structure each time a new one is needed (e.g. during a call
to fopen, freopen, or fdopen).

I really don't understand the rationale for the fixed length, static-
ally allocated array of FILE structures at all, although I'm sure that
there must have been a good reason for it at some point in time.  (In
the modern era of reentrancy however, where we eschew global data, it
does seem to me that the traditional implementation technique of static-
ally allocating a global set of FILE structures is an anachronism which
is no longer viable.  Does the POSIX 1003.1c standard reach the same
conclusion?  I wish I knew.  Unfortunately, I don't actually have a
copy... A situation which I hope to rectify in the near future.)

Obviously, the motivation for the question above relates to POSIX 1003.1c,
i.e. POSIX threads.  It occurs to me that it might be easily possible
for each independent POSIX thread in a given program to have its own
independent stdin, stdout, and stderr FILE structures.  But implement-
ing this simple, and potentially very useful bit of functionality
appears to be problematic in the context of traditional implementations
of the stdio functions, e.g. implementations which utilize a fixed-length
statically allocated array of FILE structures and implementations which
define the stdin, stdout, and stderr macros to expand merely to the
addresses of the 0'th, 1'st, and 2'nd elements of this static FILE array
(respectively).

I can easily envision an alternative implementation in which these three
macros expand to three thread-specific data values (i.e. FILE pointers)
which in turn (potentially) point to three separate and independent
thread-specific FILE structures.

I say ``potentially'' because I think it would make sense to have a
newly spawned child thread share the pre-existing stdin, stdout, and
stderr FILE structures with its parent, effectively inheriting these
from the parent... a useful default which could subsequently be over-
ridden for any given child thread.

I address my final question to the members of the POSIX 1003.1c committee:

Did you folks consider the possibility of allowing for thread-specific
stdin, stdout, and stderr files?  Is such a possibility/capability already
fully supported under POSIX 1003.1c?
--
-- Ron Guilmette, Roseville, CA -------- Infinite Monkeys & Co. ------------
---- E-mail: [e-mail] ----------- Purveyors of Compiler Test Suites -
------ Copyright (c) 1995 by Ronald F. Guilmette; All rights reserved. -----


[ Note the crossposting and Followup-To: line... -- mod ]

Volume-Number: Volume 35, Number 74